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Abstract 


Stateless Dynamic Host Configuration Protocol service for IPv6 
(DHCPv6) is used by nodes to obtain configuration information, such 
as the addresses of DNS recursive name servers, that does not require 
the maintenance of any dynamic state for individual clients. A node 
that uses stateless DHCP must have obtained its IPv6 addresses 
through some other mechanism, typically stateless address 
autoconfiguration. This document explains which parts of RFC 3315 
must be implemented in each of the different kinds of DHCP agents so 
that agent can support stateless DHCP. 


1. Introduction 


Nodes that have obtained IPv6 addresses through some other mechanism, 
such as stateless address autoconfiguration [6] or manual 
configuration, can use stateless DHCP to obtain other configuration 
information such as a list of DNS recursive name servers or SIP 
servers. A stateless DHCP server provides only configuration 
information to nodes and does not perform any address assignment. 
Such a server is called "stateless" because it need not maintain any 
dynamic state for individual clients. 


While the DHCP specification [1] defines more than 10 protocol 
messages and 20 options, only a subset of those messages and options 
are required for stateless DHCP service. This document explains 
which messages and options defined in RFC 3315 are required for 
stateless DHCP service. The intended use of the document is to guide 
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the interoperable implementation of clients and servers that use 
stateless DHCP service. 


The operation of relay agents is the same for stateless and stateful 
DHCP service. The operation of relay agents is described in the DHCP 
specification. 


Section 4 of this document lists the sections of the DHCP document 
that an implementor should read for an overview of the DHCP 
specification and the basic requirements of a DHCP service. Section 
5 lists the specific messages and options that are specifically 
required for stateless DHCP service. Section 6 describes how 
stateless and stateful DHCP servers interact to provide service to 
clients that require address assignment and clients that require only 
stateless service. 


2. Terminology 
Throughout this document, "DHCP" refers to DHCP for IPv6é. 


This document uses the terminology defined in RFC 2460 [2], the DHCP 
specification [1], and the DHCP DNS configuration options 
specification [3]. 


"Stateless DHCP" refers to the use of DHCP to provide configuration 
information to clients that does not require the server to maintain 
dynamic state about the DHCP clients. 


3. Overview 


This document assumes that a node using stateless DHCP configuration 
is not using DHCP for address assignment, and that a node has 
determined at least a link-local address as described in section 5.3 
of RFC 2461 [4]. 


To obtain configuration parameters through stateless DHCP, a node 
uses the DHCP Information-request message. DHCP servers respond to 
the node’s message with a Reply message that carries configuration 
parameters for the node. The Reply message from the server can carry 
configuration information, such as a list of DNS recursive name 
servers [3] and SIP servers [5]. 


This document does not apply to the function of DHCP relay agents as 
described in RFC 3315. A network element can provide both DHCP 
server and DHCP relay service. For example, a network element can 
provide stateless DHCP service to hosts requesting stateless DHCP 
service, while relaying messages from hosts requesting address 
assignment through DHCP to another DHCP server. 


Droms Standards Track [Page 2] 


RFC 3736 Stateless DHCP Service for IPv6 April 2004 


4. 


Basic Requirements for Implementation of DHCP 


Several sections of the DHCP specification provide background 
information or define parts of the specification that are common to 
all implementations: 


1-4: give an introduction to DHCP and an overview of DHCP message 
flows 
54 defines constants used throughout the protocol specification 


6, 7: illustrate the format of DHCP messages 
8: describes the representation of Domain Names 
9s defines the "DHCP unique identifier" (DUID) 


13-16: describe DHCP message transmission, retransmission, and 
validation 


21s describes authentication for DHCP 
Implementation of Stateless DHCP 


The client indicates that it is requesting configuration information 
by sending an Information-request message that includes an Option 
Request option specifying the options that it wishes to receive from 
the DHCP server. For example, if the client is attempting to obtain 
a list of DNS recursive name servers, it identifies the DNS Recursive 
Name Server option in the Information-request message. The server 
determines the appropriate configuration parameters for the client 
based on its configuration policies and responds with a Reply message 
containing the requested parameters. In this example, the server 
would respond with DNS configuration parameters. 


As described in section 18.1.5 of RFC 3315, a node may include a 
Client Identifier option in the Information-request message to 
identify itself to a server, because the server administrator may 
want to customize the server’s response to each node, based on the 
node’s identity. 


RFC 3315 does not define any mechanisms through which the time at 
which a host uses an Information-request message to obtain updated 
configuration parameters can be controlled. The DHC WG has 
undertaken the development of such a mechanism or mechanisms which 
will be published as Standards-track RFC(s). 
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RFC 3315 also does not provide any guidance about when a host might 
use an Information-request message to obtain updated configuration 
parameters when the host has moved to a new link. The DHC WG is 
reviewing a related document, "Detection of Network Attachment (DNA) 
in IPv4" [8], which describes how a host using IPv4 can determine 
when to use DHCPv4. Either the DHC WG or a WG formed from the DNA 
BOF will undertake development of a similar document for IPv6. 


5.1. Messages Required for Stateless DHCP Service 


Clients and servers implement the following messages for stateless 
DHCP service; the section numbers in this list refer to the DHCP 
specification: 


Information-request: sent by a DHCP client to a server to request 
configuration parameters (sections 18.1.5 and 


18.2.5) 

Reply: sent by a DHCP server to a client containing 
configuration parameters (sections 18.2.6 and 
18.2.8) 


In addition, servers and relay agents implement the following 
messages for stateless DHCP service; the section numbers in this list 
refer to the DHCP specification: 


Relay-forward: sent by a DHCP relay agent to carry the client message 
to a server (section 15.13) 


Relay-reply: sent by a DHCP server to carry a response message to 
the relay agent (section 15.14) 


5.2. Options Required for Stateless DHCP Service 


Clients and servers implement the following options for stateless 
DHCP service; the section numbers in this list refer to the DHCP 


specification: 

Option Request: specifies the configuration information that the 
client is requesting from the server (section 
22351) 

Status Code: used to indicate completion status or other status 


information (section 22.13) 


Server Identifier: used to identify the server responding to a client 
request (section 22.3) 
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Is 


5z 


Servers and relay agents implement the following options for 
stateless DHCP service; the section numbers in this list refer to the 
DHCP specification: 


Client message: sent by a DHCP relay agent in a Relay-forward message 
to carry the client message to a server (section 20) 


Server message: sent by a DHCP server in a Relay-reply message to 
carry a response message to the relay agent (section 
20) 


Interface-ID: sent by the DHCP relay agent and returned by the 
server to identify the interface to be used when 
forwarding a message to the client (section 22.18) 


3. Options Used for Configuration Information 

Clients and servers use the following options to pass configuration 

information to clients; note that other options for configuration 

information may be specified in future Internet Standards: 

DNS Recursive Name Servers: specifies the DNS recursive name servers 
[7] the client uses for name resolution; 
see "DNS Configuration options for 
DHCPv6" [3] 

DNS search list: specifies the domain names to be searched 
during name resolution; see "DNS 
Configuration options for DHCPv6" [3] 

SIP Servers: specifies the SIP servers the client uses 
to obtain a list of domain names of IPv6 
addresses that can be mapped to one or 
more SIP outbound proxy servers [5] 

4. Other Options Used in Stateless DHCP 


Clients and servers may implement the following options for stateless 
DHCP service; the section numbers in this list refer to the DHCP 
specification: 


Preference: sent by a DHCP server to indicate the preference 
level for the server (section 22.8) 


Elapsed time: sent by a DHCP client to indicate the time since the 
client began the DHCP configuration process (section 
22.9) 
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User Class: sent by a DHCP client to give additional information 
to the server for selecting configuration parameters 
for the client (section 22.15) 


Vendor Class: sent by a DHCP client to give additional information 
about the client vendor and hardware to the server 
for selecting configuration parameters for the client 
(section 22.16) 


Vendor-specific Information: used to pass information to clients in 
options defined by vendors (section 
22.17) 


Client Identifier: sent by a DHCP client to identify itself (section 
22.2). Clients are not required to send this 
option; servers send the option back if included 
in a message from a client 


Authentication: used to provide authentication of DHCP messages 
(section 21) 


6. Interaction with DHCP for Address Assignment 


In some networks, there may be both clients that are using stateless 
address autoconfiguration and DHCP for DNS configuration and clients 
that are using DHCP for stateful address configuration. Depending on 
the deployment and configuration of relay agents, DHCP servers that 
are intended only for stateless configuration may receive messages 
from clients that are performing stateful address configuration. 


A DHCP server that is only able to provide stateless configuration 
information through an Information-request/Reply message exchange 
discards any other DHCP messages it receives. Specifically, the 
server discards any messages other than Information-Request or 
Relay-forward it receives, and the server does not participate in any 
stateful address configuration message exchanges. If there are other 
DHCP servers that are configured to provide stateful address 
assignment, one of those servers will provide the address assignment. 


7. Security Considerations 


Stateless DHCP service is a proper subset of the DHCP service 
described in the DHCP specification, RFC 3315 [1]. Therefore, 
stateless DHCP service introduces no additional security 
considerations beyond those discussed in sections 21, 22.11, and 23 
of the DHCP specification [1]. 
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Configuration information provided to a node through stateless DHCP 
service may be used to mount spoofing, man-in-the-middle, denial-of- 
service, and other attacks. These attacks are described in more 
detail in the specifications for each of the options that carry 
configuration information. Authenticated DHCP, as described in 
sections 21 and 22.11 of the DHCP specification [1], can be used to 
avoid attacks mounted through the stateless DHCP service. 
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